Differential power analysis resistant encryption and decryption functions

ABSTRACT

Circuits, methods, and systems are provided for securing an integrated circuit device against Differential Power Analysis (DPA) attacks. Plaintext (e.g., configuration data for a programmable device) may be encrypted in an encryption system using a cryptographic algorithm. Ciphertext may be decrypted in a decryption system using the cryptographic algorithm. The encryption and/or decryption systems may obfuscate the plaintext, the ciphertext, and/or the substitution tables used by the cryptographic algorithm. The encryption and/or decryption systems may also generate cryptographic key schedules by using different keys for encrypting/decrypting different blocks and/or by expanding round keys between encryption/decryption blocks. These techniques may help mitigate or altogether eliminate the vulnerability of cryptographic elements revealing power consumption information to learn the value of secret information, e.g., through DPA.

FIELD OF THE INVENTION

This invention relates to methods and systems for securing theprogramming data of a programmable device—e.g., a field-programmablegate array (FPGA) or other programmable logic device (PLD)—against poweranalysis attacks, and to a programmable device so secured.

BACKGROUND OF THE INVENTION

Programmable devices are well known. In one class of known PLDs, eachdevice has a large number of logic gates, and a user programs the deviceto assume a particular configuration of those logic gates, typically byreceiving configuration data from a configuration device. Configurationdata has become increasingly complex in modern PLDs. As such,proprietary configuration data for various commonly-used functions(frequently referred to as “intellectual property cores”) have been soldeither by device manufacturers or third parties, freeing the originalcustomer from having to program those functions on its own. If a partyprovides such proprietary configuration data, it may want to protectthis data from being read, as well as any internal data that may revealthe configuration data.

Commonly-assigned U.S. Pat. Nos. 5,768,372, and 5,915,017, each of whichis hereby incorporated by reference herein in its respective entirety,describe the encryption of the configuration data and its decryptionupon loading into the programmable device, including provision of anindicator to signal to the decryption circuit which of several possibleencryption/decryption schemes was used to encrypt the configuration dataand therefore should be used to decrypt the configuration data.Commonly-assigned U.S. Pat. No. 7,479,798, which is hereby incorporatedby reference herein in its entirety, describes a disabling element thatcan be used to selectively disable a reading of a data from a device.

Cryptographic algorithms may provide one or more classes ofencryption/decryption schemes for securing the configuration data.However, these cryptographic algorithms may be vulnerable to specifickinds of attacks. One type of attack on an encryption/decryptioncryptographic system in a device is known as a power analysis attack.This approach involves observing the power consumption of the devicewhile it is executing a cryptographic algorithm. An attacker can combinethe data derived from observing the power consumption of the device withthe knowledge of the specific operations that are executed during thecryptographic algorithm, and thereby deduce information about keys andother secret data of the cryptographic algorithm.

One type of power analysis attack is known as a Differential PowerAnalysis (“DPA”) (see, for example, “Introduction to Differential PowerAnalysis and Related Attacks”, by Paul Kocher et al., of CryptographyResearch, San Francisco, Calif., copyright 1998, reprinted at web site:www.cryptography.com). DPA involves observing the power consumption of adevice while it executes cryptographic operations for a large number ofvarying inputs. By collecting and statistically correlating data fromthese multiple observations, an attacker can derive secret informationfor the cryptographic operations carried out by the device.

Different elements of a cryptographic algorithm may be particularlyvulnerable to DPA attacks. For example, key scheduling routines, usedfor generating multiple sub-keys for multiple cryptographic rounds froma secret cipher key may be especially vulnerable in this regard, giventhat these routines manipulate the cipher key in a known way. Inaddition, substitution tables (also referred to as substitution boxes or“S-boxs”), which are common in cryptographic algorithms and oftenimplemented as look up tables, may also be vulnerable to DPA attacks.Also, the initial round of encryption or final round of decryption ofsome cryptographic algorithms may be particularly vulnerable to DPAattacks, because they may only involve key manipulation withoutmodification of plaintext or ciphertext.

SUMMARY OF THE INVENTION

The present invention relates to systems and methods for protecting aprogrammable device against Differential Power Analysis attacks.

Therefore, in accordance with embodiments of the present invention, anencryption or decryption system may generate cryptographic key schedulesby using different cipher keys for each block. In some implementations,a first cipher key may be derived as a function of a second cipher keyand of one of a previous block of plaintext, a previous block ofciphertext, or an output of a linear feedback shift register (LFSR)associated with the previous block of plaintext. In someimplementations, the encryption or decryption system may expand (i.e.,evolve) round keys between encryption and/or decryption blocks. A keyexpansion block may generate from a cipher key a first sequence of roundkeys for decrypting a first block of ciphertext such that each round keyis generated based on at least one preceding round key in the firstsequence. The key expansion block may generate from at least one of theround keys of the first sequence a second sequence of round keys fordecrypting a second block of ciphertext. In some implementations, theinitial round key for decrypting a second block of plaintext is set tothe final round key used for decrypting a first block of ciphertext. Thesequence of decryption round keys may be inverted to generate a sequenceof encryption round keys.

In some embodiments, the encryption or decryption cryptographic systemthat implements the cryptographic algorithm, e.g., on a programmabledevice, is configurable to use obfuscated substitution S-boxes. S-boxesmay be obfuscated by interleaving data to be encrypted (or decrypted)with random data. In some implementations, the random data may be truerandom (e.g., generated by a True Random Number Generator). In someimplementations, the random data may be pseudo-random (e.g., generatedby a linear feedback shift register). In some implementations, therandom data may be related to another cryptographic operation for anunrelated block of data.

In some embodiments, plaintext may be obfuscated, e.g., throughwhitening using an LFSR. Blocks of plaintext may be obfuscated beforeencryption using chained encryption blocks. In some implementations, ablock of obfuscated plaintext may be further obfuscated with a block ofciphertext output from the encryption of a preceding block of plaintext.In some implementations, blocks of ciphertext may be further obfuscatedwith blocks of obfuscated plaintext.

In some embodiments, blocks of ciphertext may be obfuscated with blocksof obfuscated plaintext before decryption using chained decryptionblocks. Blocks of decrypted data may be combined with blocks ofciphertext to generate blocks of obfuscated plaintext. In someimplementations, blocks of obfuscated plaintext may be processed with anLFSR to output corresponding blocks of plaintext.

BRIEF DESCRIPTION OF THE DRAWINGS

Further features of the invention, its nature and various advantageswill be apparent upon consideration of the following detaileddescription, taken in conjunction with the accompanying drawings, inwhich like reference characters refer to like parts throughout, and inwhich:

FIG. 1 is an exemplary block diagram of a programmable device in whichembodiments of the present invention may be implemented;

FIG. 2A is an exemplary block diagram of a whitening system forobfuscating blocks of plaintext according to an embodiment of thepresent invention;

FIG. 2B is an exemplary block diagram of an unwhitening system forunwhitening blocks of obfuscated plaintext according to an embodiment ofthe present invention;

FIG. 3A is an exemplary block diagram for an encryption systemimplementing AES with continuously evolving cryptographic keys accordingto some embodiments;

FIG. 3B is an exemplary block diagram representing the continuousevolution of cryptographic keys in a decryption system according to someembodiments;

FIG. 3C is an exemplary block diagram representing the continuousevolution of cryptographic keys in an encryption system according tosome embodiments;

FIG. 4 is an exemplary block diagram of a system for obfuscating acryptographic substitution box according to some embodiments;

FIG. 5A is an exemplary block diagram of an encryption system forencrypting data according to some embodiments;

FIG. 5B is an exemplary block diagram of a decryption system fordecrypting data according to some embodiments;

FIG. 6 is an exemplary block diagram of an illustrative decryptionsystem for decrypting data employing a programmable logic deviceaccording to some embodiments;

FIG. 7A is an exemplary block diagram of an encryption system forencrypting data according to some embodiments;

FIG. 7B is an exemplary block diagram of a decryption system fordecrypting data according to some embodiments;

FIG. 8 is an exemplary block diagram of an illustrative decryptionsystem for decrypting data employing a programmable logic deviceaccording to some embodiments;

FIG. 9 shows an exemplary flowchart of a process for encrypting dataaccording to some embodiments; and

FIG. 10 shows an exemplary flowchart of a process for decrypting dataaccording to some embodiments.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 shows an exemplary block diagram of a programmable logic device100 as an example of a programmable device in which embodiments of thepresent invention may be implemented. The external memory 120 containsconfiguration data, typically containing proprietary designs, that isused to configure the functionality of the logic device 100. Theconfiguration of logic device 100 may occur upon powering up the device,rebooting, or at some other re-programming time. For example, uponpowering up, the configuration data will be sent from the externalmemory 120 to the logic device 100. The configuration data may beencrypted in order to prevent copying when the data is in transit, e.g.,using an encryption system (not shown).

The encrypted data is sent to the logic device 100 where it is decryptedby a decoder 102. The decrypted data is then stored in configurationdata memory 104. The configuration data is used to configure thefunctionality of logic blocks 106. After configuration, the logic blocksmay start operating on input data. When in operation, the logic blocksmay store internal data, e.g., in data registers, RAM, or other suitablestorage. This internal data may reflect specific aspects of theconfiguration data. Additionally, in non-programmable devices, theinternal data may reflect proprietary aspects of the circuit designwhich may be desired to be kept secret.

In some embodiments, the configuration data (which will be referred toherein as plaintext) may be encrypted using an encryption cryptographicsystem that implements a cryptographic algorithm. The decoder 102 maythen decrypt the encrypted data (i.e., ciphertext) using a correspondingdecryption cryptographic system that implements the cryptographicalgorithm.

One common cryptographic algorithm is a symmetric key block cipheralgorithm adopted by the Department of Commerce, National Institute ofStandards and Technology (NIST) as its Advanced Encryption Standard(AES). (See detailed specification in “Federal Information ProcessingStandards Publication 197” (FIPS 197), of Nov. 26, 2001.) The AESalgorithm uses cryptographic keys of 128, 192 and 256 bits to encryptand decrypt data in blocks of 128 bits. The algorithm iterates a numberof nearly identical rounds depending on key length and block size.AES128 uses 10 rounds, AES192 uses 12 rounds and AES256 uses 14 roundsto complete an encryption or decryption operation.

Although the remainder of this specification will mainly discuss the AESembodiment, it should be understood that embodiments of the inventiondescribed herein are applicable to other key lengths and block sizes aswell as to other cryptographic algorithms and modes of operation. Assuch, discussing the embodiments with respect to AES cryptographicalgorithm is exemplary and not intended to limit the scope of thepresent invention.

In some embodiments, plaintext (e.g., configuration data received in aconfiguration device for configuring programmable logic device 100 ofFIG. 1) may be processed prior to encryption with a cryptographicalgorithm. This may increase the security of the cryptographicalgorithm. For instance, blocks of plaintext may be obfuscated prior toencrypting these blocks with AES. FIG. 2A shows an exemplary blockdiagram of whitening system 200 that could be used to carry outplaintext obfuscation according to an embodiment of the presentinvention. Whitening system 200 may include a linear feedback shiftregister (LFSR) 204 coupled to combining circuitry 208.

In some implementations, combining circuitry 208 may be implemented asan exclusive-OR gate. In some implementations, combining circuitry 208may include multiplicative and/or inversion elements. Although theremainder of the patent specification will refer to the exclusive-ORgate implementation of combining circuitry 208, it should be understoodthat the invention described herein is applicable to other combiningfunctions as well. As such, discussing the embodiments with respect tothe exclusive-OR is exemplary and not intended to limit the scope of thepresent invention.

Plaintext data P (e.g., configuration data) may be partitioned into Nblocks of M bits each, e.g., P₁, P₂, P₃, . . . , and P_(N). For example,according to AES, P may be partitioned into blocks of M=128 bits. Eachblock of plaintext P_(i) (i=1, . . . , N) may be fed into input 202 ofcombining circuitry 208.

Combining circuitry 208 is coupled to LFSR 204. In some embodiments,LFSR 204 may be implemented as an M-cell shift register. During eachcycle of data transfer, an input bit, e.g., a bit from combiningcircuitry 208, may be fed into a first cell of LFSR 204, and each bit inLFSR 204 may shift down one cell. The bit in the last cell of LFSR 204may be shifted out at output 206 as an output bit. The bits output atoutput 206 will be referred to as output bitstream L. These bits may befed back to the LFSR through feedback lines 211, 212, and/or 213, suchthat they are combined with one or more of bits in predetermined cellsof the LFSR (called taps). This feedback causes the bits output by LFSR204 at output 206 to cycle through a set of unique values that mayappear random, i.e., a set of pseudo-random values.

In some embodiments, the arrangement of taps for feedback in the LFSR(i.e., the bits in the LFSR cells that influence the output as describedabove) can be expressed as a feedback polynomial, where the powers ofthe terms represent the tapped bits. In an illustrative implementation,LFSR 204 may be implemented as a 128-bit register with a characteristicfeedback polynomial POLY=X¹²⁸+X⁹⁹+X⁶²+X³³+1. According to thisimplementation, bits in cells 99, 62, and 33 may be combined to producethe output bit in the next stage. The output of the LFSR may be viewedas a division by the characteristic polynomial POLY.

Because the operation of an LFSR is deterministic, the initial valuewith which the LFSR is initialized determines the operation of theregister and may be viewed as a random seed that initializes the LFSRpseudo-random generation. In the embodiment illustrated in FIG. 2A, andreferring to the i^(th) value contained in the LFSR as R_(i), a firstblock R₀=E⁻¹ _(K0)(0) may be used to initialize LFSR 204. Because asecret key K₀ is used to generate R₀, the random seed that initializesthe LFSR pseudo-random generation is still unknown to the attacker.

Blocks of plaintext P_(i) (i=1, . . . , N) may be input into theinitialized LFSR through combining circuitry 208. Combining circuitry208 may combine the output of the LFSR with the block of plaintext P_(i)to generate a block of obfuscated plaintext P′_(i) at output 210. Forexample, the block of plaintext P_(i) may be XORed with the output ofthe LFSR to generate the block of obfuscated plaintext P′_(i). Such anoperation is referred to as whitening the block of plaintext P_(i).

Overall, the operation of whitening system 200 of FIG. 2A may beexpressed as follows:

(L ₁ ∥ . . . ∥L _(N))=(E ⁻¹ _(K0)(0)∥P ₁ ∥ . . . ∥P _(N))DIV POLY,

where POLY represents the feedback polynomial of LFSR 204, P₁∥ . . .∥P_(N) represents a concatenation (e.g., using the concatenation symbolII) of the blocks of plaintext P_(i) input at 202, E⁻¹ _(K0)(0)represents the value used to initialize LFSR 204, and L₁∥ . . . ∥L_(N)represents a concatenation of the blocks of output bits in outputbitstream L. Output bitstream L and plaintext P may be combined togenerate obfuscated or whitened plaintext P′ as follows:

(P′ ₁ ∥ . . . ∥P′ _(N))=(P ₁ ∥ . . . ∥P _(N))XOR(L ₁ ∥ . . . ∥L _(N)).

The operation of LFSR 204 may be described using the followingincremental equations:

L ₀=0,  (EQ. 1a)

R ₀ =E ⁻¹ _(K0)(0),  (EQ. 1b)

L _(i)=(R _(i−1)∥0)DIV POLY,  (EQ. 1c)

R _(i)=(R _(i−1) ∥P _(i))MOD POLY,  (EQ. 1d)

where i=1, . . . , N.

The first two equations (EQS. 1a and 1b) correspond to initializing theLFSR by setting the initial value contained in the LFSR R₀ and the firstblock of output bits L₀. As explained above, R₀ may be set to a block ofmask values generated from decrypting a vector of predetermine values(e.g., all zeros) using cipher key K₀. In this way, even if the vectorof predetermined values is predictable, the value obtained by decryptingthe vector of predetermined values using cipher key K₀ is still unknownto the attacker. In some implementations, L₀ may be set to a vector ofall zeros. It should be understood that these initialization values ofR₀ and L₀ are merely exemplary and that R₀ and L₀ may be initialized toany other suitable value.

The latter two equations (EQS. 1c and 1d) describe the operation of theLFSR, and in particular, how the output bitstream L_(i) and the LFSRstate R_(i) are updated. As explained above, the operation of the LFSRmay be viewed as performing division of the value contained in the LFSRR_(i−1) by the feedback polynomial POLY to generate output bitstreamblock L_(i). As blocks of plaintext P_(i) are input into the LFSR 204,the value contained in the LFSR R_(i) may be expressed as the result ofconcatenating the previous LFSR block (or state) R_(i−1) with a currentblock of plaintext P_(i) and taking the modulo polynomial POLY togenerate the current LFSR state R_(i).

FIG. 2B is an exemplary block diagram of an unwhitening system forunwhitening blocks of obfuscated plaintext according to an embodiment ofthe present invention. This system may be viewed as the counterpart ofFIG. 2A and comprises LFSR 254 and combining circuitry 258. Blocks ofobfuscated plaintext P′ are input into the LFSR 254 and combiningcircuitry 258. Combining circuitry 258 combines obfuscated plaintext P′and the output bitstream L to generate unwhitened plaintext P.

Blocks of obfuscated plaintext P′₁, . . . , P′_(N) may be input intoLFSR 254 and combining circuitry 258. LFSR 254 may operate similarly toLFSR 204 of FIG. 2A above. The operation of unwhitening system 250 ofFIG. 2B may be expressed as follows:

R ₀ =E ⁻¹ _(K0)(0),

L _(i)=(R _(i−1)∥0)DIV POLY,

R _(i)=(R _(i−1) ∥P _(i))MOD POLY, and

P _(i) =L _(i)XORP′ _(i),

where i=1, . . . , N. The first three equations are similar to EQS. 1b,1c, and 1d above, and describe the initialization and operation of LFSR258. The last equation describes the operation of combining circuitry258 to generate unwhitened plaintext P from XORing output bitstreamblock L_(i) and obfuscated plaintext block P′_(i).

Whitening (or unwhitening) the plaintext, as illustrated in FIGS. 2A and2B above, may increase security against DPA by masking the first roundof AES encryption (or the last round of the AES block decryption). Giventhat these rounds are particularly vulnerable to DPA attacks, and giventhat they operate on the key without modification of plaintext orciphertext, the plaintext obfuscation discussed above may increase thesecurity of the device against DPA attacks.

In some embodiments, blocks of plaintext, P_(i), or blocks of obfuscatedplaintext, P′_(i), e.g., as output by whitening system 200 of FIG. 2A,may be input to an AES encryption system. FIG. 3A is an exemplary blockdiagram of an encryption system 300 for encrypting plaintext (obfuscatedor not) using AES with a cipher key K. This cipher key K 306 may beuploaded into the engine system and/or stored in the engine system.Encryption system 300 may include a block 302 for receiving and/orstoring plaintext, a block 380 for receiving and/or storingcorresponding ciphertext, and an encryption block 304 that implementsencryption function E_(K)( ). Encryption block 304 may receive a blockof plaintext (P_(i) or P′_(i)) and generate a corresponding block ofciphertext based on cipher key K.

A block of plaintext P_(i) or obfuscated plaintext P′_(i) may be inputinto block 302. An initial key mix operation 330 may be performed inwhich the plaintext block is XORed with an initial round key 310. Innormal AES, this initial key is generated from a first portion of thecipher key K. This initial key mix operation provides the starting datafor the first round 340. In some embodiments, instead of generating thefirst round key R^(i) _(l) from the cipher key K (e.g., by expanding theinitial key 310 R^(i) ₀ that is based on the first portion of the cipherkey K), a round key for one block may be used to generate a round key ofanother block. This will be described in more detail below.

During the first round 340, the following operations occur: (a) a datablock is transformed using S-box substitution 342, row shifting 344, andcolumn mixing 346, (b) round key 312 is generated in key expansion block308, and (c) the transformed data block and round key 312 are addedtogether using an XOR operation in the AddRoundKey 348 operation toprovide the starting data block for the next round. Similar operationsare repeated for each l^(th) round 350 of AES (i.e., for each of the 14rounds for AES256) with the exception that the column mixing operationis omitted in the final round 360. The details of the S-boxsubstitution, row shifting, and column mixing operations for the roundsare described in the above-mentioned NIST document.

A sequence of round keys for each encryption round (or key schedule) isgenerated from the initial cipher key K using a key expansion routine,e.g., implemented by block 308. In AES, the length of the round keys isthe same as the block size (128 bits=4 words) regardless of the length(128, 192, or 256 bits) of the original cipher key. The words of thecipher key are used as is for generating the first round keys, then eachsuccessive round key word is a function of one or more of the precedinground key words. This generating of each successive round key word basedon at least one of the preceding round key words will be referred toherein as the evolution of round keys. In AES256, encryption anddecryption for a particular block evolve the round keys in reverseorder. If the fourteen decryption round keys for block 1 are R¹ _(l)through R^(l) ₁₄, then the encryption round keys for block 1 will be R¹₁₄ through R¹ ₁.

According to some embodiments, the cipher key used for encryptingsubsequent blocks of plaintext or obfuscated plaintext is different withevery block. This is different from normal AES where the same keyschedule based on the same cipher key K is used for every block and theinitial round key (i.e., round key 310) used in the first round of AESfor every block is filled from the first words of the cipher key K. Insome embodiments, encrypting a first block of plaintext P₁ (or P′₁) mayuse the same sequence of 14 round keys (or key schedule) as normal AESbased on the original cipher key K. However, encrypting a second blockof plaintext P₂ (or P′₂) may use a different key schedule. For example,a sequence of round keys for encrypting P₂ may be based on expanding aninitial round key that is different from the one used for P₁.

In some embodiments, every block may be encrypted using a different keysuch that the keys for encrypting subsequent blocks of plaintext arerelated. In some implementations, the round keys for encryptingdifferent blocks of plaintext may continue to evolve between blocks. Forexample, the key used for encrypting a block of plaintext or obfuscatedplaintext may be derived based on a function of the previous plaintext,the previous ciphertext, the previous key used to encrypt the previousplaintext or decrypt the previous ciphertext, and/or the previous LFSRvalue used to whiten the previous plaintext or unwhiten the previousciphertext.

FIG. 3B is an exemplary block diagram representing the continuousevolution of cryptographic keys in a decryption system according to someembodiments. In the example illustrated in FIG. 3B, each row maycorrespond to one cryptographic round and each column may correspond toone block of ciphertext. In the particular example of FIG. 3B, 14decryption rounds and three blocks are illustrated. Each box depicts adecryption round key R^(n) _(l) that may be used to decrypt block nduring round l. The decryption keys of each column form a sequence ofkeys associated with one block of ciphertext. As explained above inconnection with key expansion block 308 of FIG. 3A, a decryption roundkey R^(n) _(l+1) may be derived from a decryption round key of aprevious round, e.g., R^(n) _(l). The relationship between thedecryption round keys associated with one block may be expressed using afunction f_(l)( ) where l refers to the decryption round. This functionf_(l)( ) may describe the intra-block round key evolution used fromdecryption round key R^(n1) to decryption round key R^(n) _(l+1). ForAES128, the round key for block n and round l+1 can be derived as afunction f( ) of the previous round key (i.e., R^(n) _(l+1)=f(R^(n)_(l)) because f_(l)( ) is the same, regardless of round l). For AES256,the even and odd rounds have different functions because the even andodd round keys are a function of the upper and lower 128 bits of thecipher key K. Other types of block ciphers may have different functionsfor each round.

According to some embodiments of the present disclosure, the decryptionround key for a block n may depend on the value of a decryption roundkey for a previous block n−1. For example, the first round decryptionkey for block n may be derived from the last round decryption key usedfor block n−1. An intra-block function f_(l)( ) may be defined to extendthe inter-block function f_(l)( ) described above and describe theevolution of decryption round keys between blocks, i.e., such thatR^(n+1) _(l), =f_(l)(R^(n) _(l)). For example, and as shown by the arrowfrom the first to the second column labeled f₁₄( ), the decryption roundkey R² ₁ may be obtained from the decryption round key of the previousblock, R¹ ₁₄, by applying inter-block function f₁₄( ) (i.e., R² ₁=f₁₄(R¹₁₄)). This means that the key evolution of decryption round keys maycontinue between blocks. In standard AES256, f₁₄( ) is not strictlydefined (as the key is evolved, i.e., expanded, only 13 times to get 14round keys, and the key of the first round key for the second block isregenerated from cipher key K, i.e., similarly to the first round keyfor the first block). In some embodiments that employ intra-block keyevolution with an AES engine, f₁₄( ) may be defined to be equal to thedecryption key evolution function of the last even round, i.e., f₁₂( ).

The relationship between the decryption round keys illustrated in FIG.3B may also define the relationship between encryption round keys R^(n)₁₄, . . . , R^(n) ₁ used for encryption. FIG. 3C is an exemplary blockdiagram representing the continuous evolution of cryptographic keys inan encryption system with 14 encryption rounds and three blocks. Lettingf⁻¹ _(l)( ) correspond to the inverse of the decryption key evolutionfunction f_(l)( ) described above (both within and between blocks, i.e.,inter and intra-block), the evolution of encryption round keys withineach block n may be defined as R^(n) _(l)=f⁻¹¹ _(l)(R^(n) _(l+1)). Theevolution of encryption round keys between blocks n+1 and n may bedefined by R^(n) ₁₄=f⁻¹ _(l)(R^(n+1) _(l)). This evolution of encryptionround keys may be viewed as the inverse of the evolution of thedecryption keys of FIG. 3B.

In some embodiments, it may not be practical to evolve the encryptionkeys from the last block to the first block in order to startingencrypting the first block. For example, it may not be practical tostart from R³ ₁₄ to compute R¹ ₁ by sequentially applying f⁻¹ _(l)( ),per the order illustrated in FIG. 3. Instead of computing the encryptionround keys backwards from the last block to the first block, the 14encryption round keys R^(n) ₁₄, . . . , R^(n) ₁ may be obtained by firstexpanding the 14 decryption round keys R^(n) ₁, . . . , R^(n) ₁₄. Inother words, each sequence of encryption round keys associated withblock n (i.e., R^(n) ₁₄, . . . , R^(n) ₁) may be computed by generatingthe corresponding sequence of decryption round keys (i.e., R^(n) ₁, . .. , R^(n) ₁₄, as described in FIG. 3B above), and then inverting theorder of the generated sequence of decryption round keys.

As discussed above, key schedule routines are specifically vulnerable toDPA attacks. According to one approach, an attacker may generate twolarge sets of ciphertext blocks and monitor the power consumption of adevice while the device decrypts both sets of ciphertexts. Statisticalanalysis of the difference in power consumption between both sets mayhelp derive information about the cipher key. The techniques describedabove of letting the round keys continue to evolve between blockencryptions may increase the security of the device against these typesof attacks because the keys used to decrypt the ciphertexts may varywith each block.

In some embodiments, the intra-block key evolution approach described inFIGS. 3A-3C above may be applied to cipher block modes of operation e.g.Counter Mode (CTR) or Cipher-Block-Chaining mode (CBC). In someembodiments, the evolving key approach may be combined with any otherDPA resistant methods and systems such as the ones described herein.

In some embodiments, the security of the device against DPA may furtherbe enhanced by obfuscating the substitution blocks used in acryptographic algorithm, e.g., the S-box used in the S-box substitutionoperation 342 of FIG. 3A. FIG. 4 is an exemplary block diagram of system400 for obfuscating a cryptographic substitution box according to anembodiment of the present invention. System 400 includes S-box 206,which may be implemented in hardware or software on an encryptiondevice, e.g., on a PLD or an encryption system in configuration device.An S-box is a typical component of symmetric key cryptographicalgorithms that is used to obscure the relationship between the key andthe data to be encrypted or decrypted. The S-box may be implemented as atable lookup that is indexed by a combination of key bits and plaintext.For example, each byte of input text 202 may be replaced with anotherbyte 208 according to the look up table and using the cipher key K.

S-boxes may be vulnerable to DPA attacks. An attacker may control theplaintext values and make guesses at the key bits. Based on theseguesses, computations are performed on the monitored power consumptionto form a set of DPA data. The DPA data is analyzed to determine with ofthe key bit guesses was likely correct. These types of attacks may bemitigated by obfuscating S-boxes used, for example, during AES.

In some embodiments, S-box 206 may be obfuscated by interleaving inputdata 202 with random data 204. This random data may not be part of theplaintext or ciphertext. In some implementations, random data 204 may betrue random, e.g., generated by a true random number generator (TRNG)implemented in an FPGA. In some implementations, random data 204 may bepseudo-random, e.g., generated with an LFSR similar to LFSR 204 fromFIG. 2. In some implementations, random data 204 may be generated from aseparate cryptographic method operating on an unrelated block of data.

In addition to or instead of the techniques described above forobfuscating plaintext, continuously evolving cryptographic round keys,and/or obfuscating substitution tables, security of a device may beenhanced by obfuscating ciphertext as illustrated in FIGS. 5-8 below.

FIG. 5A shows an exemplary block diagram of encryption system 500 forencrypting data according to some embodiments. Encryption system 500 mayinclude encryption blocks 506, 516, 526, and 536. These encryptionblocks may be implemented as encryption block 300 of FIG. 3A, usingnormal AES or AES modified to use continuously evolving keys. System 500may also include combining circuitries 502, 512, 522, 532, 504, 514,524, 534, 508, 518, 528, and 538. Each one of these combiningcircuitries may be implemented similarly to combining circuitry 208 ofFIG. 2A. It should be noted that the number of encryption blocks and thenumber of combining circuitries are exemplary and not intended to limitthe scope of the present invention.

Blocks of plaintext P₁, P₂, P₃, and P₄ are whitened using whiteningbistream blocks L₁, L₂, L₃, and L₄. These whitening bistream blocks maybe generated using an LFSR as described in FIG. 2A above. The plaintextblocks and whitening bistream blocks are combined using combiningcircuitries 502, 512, 522, and 532 to output blocks of obfuscatedplaintext P′₁, P′₂, P′₃, and P′₄. The first block of plaintext P₁ may beset to an initialization vector (IV). An IV is a fixed-size seed inputto a cryptographic mode that is typically random or pseudorandom. Forblock ciphers, the use of an IV randomizes the encryption and henceproduces distinct ciphertexts even if the same plaintext (P₂, P₃, . . .) is encrypted multiple times.

The blocks of obfuscated plaintext P′₁, P′₂, P′₃, and P′₄ are furtherobfuscated by combining them, respectively, with blocks of ciphertextC₀, C₁, C₂, and C₃ using combining circuitries 504, 514, 524, and 534.In some embodiments, ciphertext block C₀ may be initialized to zero, orto any other suitable value. Ciphertext blocks C₁, C₂, and C₃ are outputfrom encryption blocks 506, 516, and 526, respectively, as will bediscussed below. The blocks resulting from combining the blocks ofobfuscated plaintext and the blocks of ciphertext are referred to asblocks of further obfuscated plaintext H₁, H₂, H₃, and H₄.

Blocks H₁, H₂, H₃, and H₄ are encrypted using encryption blocks 506,516, 526, and 536 to generate ciphertext blocks C₁, C₂, C₃, and C₄. Insome embodiments, encryption blocks 506, 516, 526, and 536 may usedifferent cipher keys K₁, K₂, K₃, and K₄. For example, the keys K₁, K₂,K₃, and K₄ may be obtained using the evolving key approach described inFIGS. 3A-C above. In some embodiments, encryption blocks 506, 516, 526,and 536 may use the same cipher key, e.g., as defined in normal AES(K₁=K₂=K₃=K₄).

The first obfuscated block H₁ is fed into the first encryption block 506to generate a block of ciphertext C₁=E_(K1)(H₁), i.e., the result ofencrypting H₁ with cipher key K₁. Combining circuitry 508 combines theoutput of the first encryption block 506 with a block of mask valuesH₀=E⁻¹ _(K0)(0) to generate a first block of obfuscated ciphertext C′₁.This block of mask values may be generated by decrypting a vector of allzeros using cipher key K₀. This first block of obfuscated ciphertext C′₁may thus be expressed as C₁ XOR H₀.

The block of ciphertext C₁ is combined with the second block ofobfuscated plaintext P′₂ using combining circuitry 514. The output ofcombining circuitry 514, H₂, is fed into the second encryption block516. Second encryption block 516 encrypts H₂ to generate a second blockof ciphertext C₂=E_(K2)(H₂). Combining circuitry 518 combines the firstblock of further obfuscated plaintext H₁ with the second block ofciphertext C₂ to generate a second block of obfuscated ciphertext C′₂.The operation of combining circuitry 518 may be viewed as whitening theblock of ciphertext C₂ with the prior block of further obfuscatedplaintext H₁ to output the block of obfuscated ciphertext C′₂.

Similar operations may be repeated to generate a third block and fourthblock of ciphertext C₃ and C₄ and a third block and fourth block ofobfuscated ciphertext C′₃ and C′₄.

In general, the blocks of obfuscated plaintext, further obfuscatedplaintext, ciphertext, and obfuscated ciphertext that are output byencryption system 500 may be expressed using the following equations:

L ₀=0,  (EQ. 1a)

R ₀ =E ⁻¹ _(K0)(0),  (EQ. 1b)

L _(i)=(R _(i−1)∥0)DIV POLY,  (EQ. 1c)

R _(i)=(R _(i−1) ∥P ₁)MOD POLY,  (EQ. 1d)

H ₀ =E ⁻¹ _(K0)(0),  (EQ. 2a)

C ₀=0,  (EQ. 2b)

P ₁ =IV,  (EQ. 2c)

P′ _(i) =L _(i)XORP _(i),  (EQ. 3a)

H _(i) =P′ _(i)XORC _(i−1),  (EQ. 3b)

C _(i) =E _(Ki)(H _(i)),  (EQ. 3c)

C′ _(i) =C _(i)XORH _(i−1),  (EQ. 3d)

where i=1, . . . , N. The first set of equations, EQS. 1a, 1b, 1c, and1d, is the same as the incremental LFSR equations of FIG. 2A andcorresponds to the generation of bitstream blocks L₁, L₂, L₃, and L₄.The second set of equations, EQS. 2a, 2b, and 2c, corresponds toinitialization values for the inputs of combining circuitries 504, 508,and 502, respectively. The third set of equations, EQS. 3a, 3b, 3c, and3d, represents the relation between blocks of plaintext P_(i), blocks ofobfuscated plaintext P′_(i), blocks of further obfuscated plaintextH_(i), blocks of ciphertext C_(i), and blocks of obfuscated ciphertextC′_(i), as described above. It should be noted that the initializationvalues are merely illustrative, and that any suitable value may be usedto initialize L₀, R₀, H₀, C₀ and P₁.

The blocks of obfuscated ciphertext output by encryption system 500 maybe decrypted using decryption system 550 illustrated in FIG. 5B.Decryption system 550 may include decryption blocks 554, 564, 574, and584, and combining circuitries 552, 562, 572, 582, 556, 566, 576, 586,558, 568, 578, and 588. These combining circuitries may be implementedsimilarly to combining circuitry 208 of FIG. 2A. It should be noted thatthe number of decryption blocks and the number of combining circuitriesare exemplary and not intended to limit the scope of the presentinvention.

Blocks of obfuscated ciphertext C′₁, C′₂, C′₃, and C′₄ are fed intodecryption system 550. These blocks of obfuscated ciphertext may forexample have been output from encryption system 500 of FIG. 5A.Combining circuitry 552 may combine a first block of obfuscatedciphertext C′1 with a block of mask values H₀=E⁻¹ _(K0)(0). In someimplementations, the block of mask values may be generated similarly toFIG. 5A, i.e., by decrypting a vector of all zeros using cipher key K₀.Combining circuitry 552 may output a ciphertext block C₁=C′₁ XOR H₀,which is fed into the first decryption block 554. First decryption block554 decrypts ciphertext block C₁ with cipher key K₁ to produce a firstblock of further obfuscated plaintext H₁.

The first block of further obfuscated plaintext H₁ may be combined witha block of ciphertext C₀ using combining circuitry 556. The output ofthe combining circuitry 556 corresponds to obfuscated plaintext blockP′₁. This block of obfuscated plaintext P′₁ may be unwhitened withbistream block L₁ to generate a block of plaintext P₁. The bistreamblock L₁ may be generated by an LFSR such as the one depicted in FIG.2B.

The block of further obfuscated plaintext H₁ is combined with obfuscatedciphertext block C′₂ using combining circuitry 562 to generate a blockof ciphertext C₂. This block of ciphertext C₂ is decrypted usingdecryption block 564 to generate H₂. Block H₂ is combined withciphertext block C₁ to generate obfuscated plaintext block P′₂. Thisblock of obfuscated plaintext P′₂ may be unwhitened similarly to P′₁ inorder to generate plaintext block P₂.

Similar operations may be repeated to generate a third and fourth blockof obfuscated plaintext P′₃ and P′₄, and a third and fourth block ofplaintext P₃ and P₄. The operation of decryption system 550 may besummarized using the following equations:

R ₀ =E ⁻¹ _(K0)(0),  (EQ. 4a)

L _(i)=(R _(i−1)∥0)DIV POLY,  (EQ. 4b)

R _(i)=(R _(i−1) ∥P _(i))MOD POLY,  (EQ. 4c)

H ₀ =E ⁻¹ _(K0)(0),  (EQ. 5a)

C ₀=0,  (EQ. 5b)

C _(i) =C′ _(i)XORH _(i−1),  (EQ. 6a)

H _(i) =E ⁻¹ _(Ki)(C _(i)),  (EQ. 6b)

P′ _(i) =H _(i)XORC _(i−1),  (EQ. 6c)

P _(i) =L _(i)XORP′ _(i),  (EQ. 6d)

where i=1, . . . , N. The first set of equations, EQS. 4a, 4b, and 4c,is the same as the incremental LFSR equations of FIG. 2B and correspondsto the generation of bitstream blocks L₁, L₂, L₃, and L₄. The second setof equations, EQS. 5a and 5b, corresponds to initialization values forthe inputs of combining circuitries 552 and 556, respectively. The thirdset of equations, EQS. 6a, 6b, 6c, and 6d, represents the relationbetween blocks of obfuscated ciphertext C′_(i), blocks of ciphertext C₁,blocks of further obfuscated plaintext H₁, blocks of obfuscatedplaintext P′_(i), and blocks of plaintext P_(i), as described above.These equations are the reverse of the encryption equations 3a, 3b, 3c,and 3d above. It should be noted that the initialization values aremerely illustrative, and that any suitable value may be used toinitialize R₀, H₀, and C₀.

Although the encryption and decryption blocks and operations illustratedin FIGS. 5A and 5B above use cipher keys with different indices K₁, K₂,K₃, and K₄, it should be understood that these cipher keys may be thesame or different. In some implementations, these keys may be set to onevalue K, e.g., for normal AES (K₁=K₂=K₃=K₄). In some implementations,these keys may be different and may be generated using the evolving keyapproach described in FIGS. 3A-C above.

An illustrative implementation of the decryption system of FIG. 5B isshown in FIG. 6. Decryption system 600 of FIG. 6 may include M-bit shiftregisters 604 and 618, M-bit linear feedback shift register (LFSR) 640,decryption engine 614, registers 608 and 609, and combining circuitries610, 616, and 644. LFSR 640 may be implemented similarly to LFSR 204 ofFIG. 2B. Combining circuitries 610, 616, and 644 may be implementedsimilarly to combining circuitry 208 of FIG. 2A.

Input shift register 604 may receive blocks of obfuscated ciphertextC′_(i) (i=1, . . . , N). These blocks may be output, for example, fromencryption system 500 of FIG. 5A. In some embodiments, the blocks ofobfuscated ciphertext may be received sequentially by shift register604, such that, as input shift register 604 is receiving C′_(i+2), inputshift register 604 is outputting C′_(i+1), register 608 is outputtingC′_(i), and register 609 is outputting C′_(i−1). This arrangement ismerely illustrative, and any number of registers 608 or 609 orconfigurations of input shift register 604 may be used as appropriate.

Combining circuitry 610 may receive a first block of obfuscatedciphertext C′_(i+1) from shift register 604 and combine it with anoutput of decryption engine 614 to generate a corresponding block ofciphertext C_(i+1). The output of combining circuitry 610 is coupled tothe decryption engine 614. Decryption engine 614 may decrypt the firstblock of ciphertext C_(i+1) to output a first block of furtherobfuscated plaintext H_(i), e.g., as specified in EQ. 6a above. Theblock of further obfuscated plaintext H_(i) may be fed back to combiningcircuitry 610 to generate the corresponding block of ciphertext C_(i+1),e.g., as specified in EQ. 6b above.

The output of combining circuitry 610 may also be coupled to seriallyconnected registers 608 and 609, for storing the previous two generatedciphertext blocks C_(i) and C_(i+1), respectively. Combining circuitry616 may combine the block of ciphertext output by register 609 (e.g.,C_(i−1)) with the block of further obfuscated plaintext H_(i) to outputa block of obfuscated plaintext P′_(i), as specified in EQ. 6c above.

The block of obfuscated plaintext P′_(i) (i=1, . . . , N) may be inputinto shift register 618, which is coupled to combing circuitry 644 andLFSR 640. Combining circuitry 644 and LFSR 640 are arranged similarly tosystem 250 of FIG. 2B above, and are configurable to unwhiten the blockof obfuscated plaintext P′_(i) to generate a block of plaintext P_(i),e.g., as described in EQ. 6d above.

In some embodiments, the feedback line 620 from the output of decryptionengine 614 to the input of combining circuitry 610 may be selectivelydisabled. By disabling this feedback line, decryption engine 614 mayimplement decryption algorithm using normal CBC mode (i.e., withoutwhitening obfuscated ciphertext blocks with prior plaintext blocksH_(i).)

The techniques of obfuscating plaintext and ciphertext described abovemay help make a device more secure against DPA. First, by masking boththe input and output of the AES engine, DPA attacks may be prevented onthe first and last round of a single block decryption, which aretypically the most vulnerable rounds. Second, the attacker may beprevented from injecting multiple known ciphertext blocks with varyingdifferent bits, because all subsequent ciphertext blocks would becryptographically corrupted. For example, an attacker may toggle bits ofonly one ciphertext block, C′₁, in a known fashion, and analyze thepower profiles of the device while the device decrypts a large number ofciphertexts differing in this one ciphertext block C′_(i). Using thetechniques for whitening or obfuscating ciphertext blocks describedabove, changing one ciphertext block would propagate across allfollowing ciphertext blocks, which would make this type of attacksubstantially more difficult.

In some embodiments, decryption engine 614 may decrypt each block C_(i)using the same cipher key K. In some embodiments, decryption engine 614may implement continuously evolving key as described in FIGS. 3A-Cabove. For example, decryption engine 614 may expand cipher key K fromone block to the next. For instance, the first round key in decryptingciphertext block C₂ may be initialized to the value of the final roundkey used in decrypting ciphertext block C₁.

In some embodiments, AES decryption engine 614 may implement the S-boxobfuscation described in FIG. 4 above. In some implementations,decryption engine 614 may implement the AES algorithm using 4 S-boxesthat are obfuscated as described in FIG. 4 above, e.g., using truerandom or pseudo-random data.

FIGS. 7A, 7B, and 8 are variants of the encryption and decryptionsystems illustrated in FIGS. 5A, 5B, and 6, respectively.

FIG. 7A is an exemplary block diagram of an encryption system 700 forencrypting data according to some embodiments. System 700 may operatesimilar to system 500 of FIG. 5A, except that ciphertext blocks C_(i)are obfuscated with blocks of obfuscated plaintext P′_(i−1), instead ofwith blocks of further obfuscated plaintext H_(i−1) as is the case insystem 500. For example, combining circuitry 718 is coupled to an outputof combining circuitry 702 through line 710. In contrast, in FIG. 5A,combining circuitry 518 is coupled to an output of combining circuitry504 through line 510.

The operation of system 700 may be described using equations similar tosystem 500, with EQS. 2a and 3 d modified as follows:

P′ ₀ =E ⁻¹ _(K0)(0),  (EQ. 2a′)

C′ ₁ =C _(i)XOR P′ _(i−1).  (EQ. 3d′)

The value P′₀ of EQ. 2a′ corresponds to the initialization value for theinput of combining circuitry 708. It should be noted that thisinitialization value is merely illustrative, and that any suitable valuemay be used to initialize P′₀. The obfuscation of ciphertext blocksusing previous obfuscated plaintext blocks is shown in EQ. 3d′.

FIG. 7B is an exemplary block diagram of a decryption system 750 fordecrypting data according to some embodiments. System 750 may operatesimilar to system 550 of FIG. 5B, except that obfuscated ciphertextblocks C′_(i) are unwhitened with blocks of obfuscated plaintextP′_(i−1), instead of with blocks of further obfuscated plaintext H_(i−1)as is the case in system 550. For example, combining circuitry 762 iscoupled to an output of combining circuitry 756 through line 760. Incontrast, in FIG. 5B, combining circuitry 562 is coupled to an output ofdecryption block 554 through line 560.

The operation of system 750 may be described using equations similar tosystem 550, with EQS. 5a and 6 a modified as follows:

P′ ₀ =E ⁻¹ _(K0)(0),  (EQ. 5a′)

C _(i) =C′ _(i)XORP′ _(i−1),  (EQ. 6a′)

The value P′₀ of EQ. 5a′ corresponds to the 2a′ corresponds to theinitialization value for the input of combining circuitry 756. It shouldbe noted that this initialization value is merely illustrative, and thatany suitable value may be used to initialize P′₀. The unwhitening ofobfuscated ciphertext blocks using previous obfuscated plaintext blocksis shown in EQ. 6a′.

An illustrative implementation of the decryption system of FIG. 7B isshown in FIG. 8. System 800 of FIG. 8 may operate similar to system 600of FIG. 6, except that feedback line 820 connects an output of combiningcircuitry 818 to combining circuitry 810. In contrast, in FIG. 6,feedback line 620 connects the output of the decryption engine tocombining circuitry 610. This modification reflects EQ. 6a′ above, suchthat blocks of obfuscated ciphertext are unwhitened using previousblocks of obfuscated plaintext P′_(i), rather than previous blocks offurther obfuscated plaintext H_(i).

FIG. 9 shows an exemplary flowchart of process 900 for encrypting datain accordance with some embodiments. Process 900 may be executed, forexample, in a system for encrypting configuration data that may beexternal or internal to a programmable device.

At 902, plaintext is received, for example, configuration data forconfiguring PLD 100 of FIG. 1 is received at the encryption system.

At 904, it is determined whether plaintext obfuscation is enabled. Forexample, a bit register in the configuration device may be set to enableor disable this feature. In some embodiments, plaintext obfuscation mayalways be enabled. If plaintext obfuscation is enabled, then plaintextis whitened at step 906, for example, as described in FIG. 2A above.Step 908 may then be performed. Alternatively, if plaintext obfuscationis disabled, then 908 may be immediately performed.

At 908, it is determined whether continuous key evolution is enabled.For example, a bit register in the configuration device may be set toenable or disable allowing the key to continue to evolve in betweenblocks. This may be useful for users who want to implement AES strictlyaccording to the NIST standard, i.e., by generating round keys for eachblock encryption starting from the cipher key. If continuous keyevolution is not enabled, then 912 may be performed. Alternatively, ifat 908 key evolution mode is enabled, then 910 may be performed.

At 910, plaintext (or obfuscated plaintext from 906 if plaintextwhitening is enabled) is encrypted with such that different blocks areencrypted with different keys, as described in connection with FIGS.3A-C above. Otherwise, at 912, plaintext (or obfuscated plaintext from906 if plaintext whitening is enabled) is encrypted using normal AES,i.e., using the original cipher key for generating the sequence of roundkeys (key schedule).

At 914, it is determined whether S-box obfuscation is enabled. Forexample, a bit register in the configuration device may be set to enableor disable this feature. Given that obfuscating cryptographic S-boxesmay add computational overhead, a user may wish to disable this featurein some implementations.

If S-box obfuscation is enabled, plaintext is encrypted at 916 usingobfuscated S-boxes as described in connection with FIG. 4 above, whereplaintext is input into the obfuscated S-box. If S-box obfuscation isdisabled, plaintext is encrypted at 918 using non-obfuscated S-boxes,such as the normal AES S-boxes.

At 920, it is determined whether ciphertext obfuscation is enabled. Ifit is, 922 may be performed. Otherwise, 924 may be performed.

At 922, encryption is carried out by whitening output blocks ofciphertext with blocks of plaintext (that may have been whitened or notat 906). This may be implemented using encryption system 500 of FIG. 5Aor encryption 700 of FIG. 7A.

Alternatively, if ciphertext obfuscation is not enabled, then the normalcryptographic method (e.g., AES encryption) may be implemented usingnormal CBC mode.

Finally, at 930, ciphertext corresponding to the plaintext received at902 is output.

FIG. 10 shows an exemplary flowchart of process 1000 for decrypting datain accordance with some embodiments. Process 1000 may be executed, forexample, in a system for decrypting configuration data in a programmabledevice, e.g., decoder 102 of programmable logic device 100 of FIG. 1.

At step 1002, ciphertext is received, for example, encryptedconfiguration data for configuring PLD 100 of FIG. 1 is received at thedecryption system, or ciphertext output by encryption process 900 ofFIG. 9.

At 1004, it is determined whether ciphertext obfuscation is enabled. Forexample, feedback lines 620 of FIG. 6 or 820 of FIG. 8 may be enabled inthis case. If ciphertext obfuscation is enabled, 1006 may be performed.Otherwise, 1008 may be performed.

At 1006, decryption is carried out by whitening ciphertext with blocksof plaintext. This may be implemented using decryption systems 550 ofFIG. 5B, 600 of FIG. 6, 750 of FIG. 7B, or 800 of FIG. 8. Alternatively,at 1008, if ciphertext obfuscation is not enabled, then the normalcryptographic method (e.g., AES decryption) may be implemented usingnormal CBC mode. For example, feedback lines 620 of FIG. 6 or 820 ofFIG. 8 may be disabled in this case.

At 1010, it is determined whether S-box obfuscation is enabled. If S-boxobfuscation is enabled, ciphertext is decrypted at 1012 using obfuscatedS-boxes as described in connection with FIG. 4 above, where ciphertextis input into the obfuscated S-box. Otherwise, if S-box obfuscation isdisabled, ciphertext is decrypted using non-obfuscated S-boxes at 1014,such as the normal AES S-boxes.

At 1016, it is determined whether continuous key evolution is enabled.If continuous key evolution is disabled, then ciphertext may bedecrypted using normal AES decryption at 1020. Alternatively, if the keyevolution mode is enabled, then 1018 may be performed.

At 1018, ciphertext is decrypted with a continuously evolving key, asdescribed in connection with FIGS. 3A-B. In some implementations,different cipher keys may be used to decrypt different blocks. In someimplementations, while running the AES decryption based on cipher key K,decryption of a subsequent block may use round keys that have beenexpanded from the key schedule of a previous block decryption.

At 1022, it is determined whether plaintext obfuscation is enabled. Ifplaintext obfuscation is enabled, then whitened plaintext is whitened atstep 1024, for example, as described in FIG. 2B above. In particular,whitening blocks of whitened plaintext using LFSR 254 and combiningcircuitry 258 of FIG. 2B may generate corresponding blocks of plaintext.

Finally, at 1026, plaintext (e.g., corresponding to configuration data)that corresponds to ciphertext received at 1002 is output.

It will be understood that the above steps of processes 900 and 1000 maybe executed or performed in any order or sequence not limited to theorder and sequence shown and described in the figure. Also, some of theabove steps of process 900 and 1000 may be executed or performedsubstantially simultaneously where appropriate or in parallel to reducelatency and processing times.

It will be understood that the foregoing is only illustrative of theprinciples of the invention, and that various modifications can be madeby those skilled in the art without departing from the scope and spiritof the invention. For example, the various elements of this inventioncan be provided on a PLD in any desired number and/or arrangement. Oneskilled in the art will appreciate that the present invention can bepracticed by other than the described embodiments, which are presentedfor purposes of illustration and not of limitation, and the presentinvention is limited only by the claims that follow.

1-20. (canceled)
 21. A system, comprising: an electronic device togenerate an encrypted bitstream to configure a field programmable gatearray (FPGA), wherein the electronic device is operable to: encrypt afirst block of an unencrypted bitstream based on a first key to generatea first encrypted block of the encrypted bitstream; encrypt a secondblock of the unencrypted bitstream based on a second key to generate asecond encrypted block of the encrypted bitstream; and encrypt a thirdblock of the unencrypted bitstream based on a third key to generate athird encrypted block of the encrypted bitstream; and the FPGA, whereinthe FPGA is operable to receive the encrypted bitstream and use aninternal decryption engine to: decrypt the first encrypted block basedon the first key; obtain the second key based on the decryption of thefirst encrypted block; decrypt the second encrypted block based on thesecond key; obtain the third key based on the decryption of the secondencrypted block; and decrypt the third encrypted block based on thethird key.
 22. The system of claim 21, wherein the encrypted bitstreamis stored in an off-chip memory prior to sending the encrypted bitstreamto the FPGA.
 23. The system of claim 21, wherein the FPGA stores thefirst key in an on-chip memory of the FPGA.
 24. The system of claim 21,wherein the internal decryption engine decrypts using an AdvancedEncryption Standard (AES) algorithm.
 25. The system of claim 21, whereinthe first key, the second key, and the third key are different from oneanother.
 26. The system of claim 21, wherein the encrypted bitstreamresults in a disabled readback of configuration.
 27. The system of claim21, wherein the first key comprises a user-supplied key.
 28. The systemof claim 21, wherein the first key is obfuscated.
 29. The system ofclaim 21, wherein the decrypted first block, the decrypted second block,the decrypted third block, or a combination thereof, are stored asconfiguration data in configuration memory of the FPGA.
 30. The systemof claim 29, wherein the configuration data is used to configure theFPGA.
 31. The system of claim 21, wherein the first key is a symmetrickey enabling access to the encrypted bitstream.
 32. A field programmablegate array (FPGA) configured to receive a plurality of blocks of anencrypted bitstream, the FPGA comprising: a plurality of configurablelogic blocks; a decryption engine configured to: decrypt a first blockof the plurality of blocks, wherein decrypting the first block is basedon a first key; and decrypt successive blocks of the plurality of blocksusing successive keys, wherein the successive keys are determined basedon a previously decrypted block of the plurality of blocks; andconfiguration memory configured to store at least part of the decryptedfirst block, the decrypted successive blocks, or some combinationthereof, as configuration data, wherein the configuration dataconfigures the plurality of configurable logic blocks of the FPGA. 33.The FPGA of claim 32, wherein the plurality of blocks are stored in anexternal memory device separate from the FPGA before decryption by thedecryption engine.
 34. The FPGA of claim 32, wherein the first key isstored on an on-chip memory of the FPGA.
 35. The FPGA of claim 32,wherein the decrypting comprises using an Advanced Encryption Standard(AES) algorithm.
 36. The FPGA of claim 32, wherein the successive keysare unique keys.
 37. A method for configuring a field programmable gatearray (FPGA) with an encrypted bitstream, comprising: partitioning anunencrypted bitstream into a plurality of blocks; encrypting a firstblock of the plurality of blocks based on a first key; encryptingsuccessive blocks of the plurality of blocks based on successive keys;transmitting the encrypted plurality of blocks to a decryption engine todecrypt the encrypted plurality of blocks; direct a decryption of thefirst block based on the first key; and direct a decryption of thesuccessive blocks based on the successive keys, wherein the successivekeys are determined based on a decryption of a previously encryptedblock of the successive blocks.
 38. The method of claim 37, wherein thefirst key is stored in an on-chip memory of the FPGA.
 39. The method ofclaim 37, wherein the decrypted first block, the decrypted successiveblocks, or a combination thereof, are stored as configuration data inconfiguration memory of the FPGA.
 40. The method of claim 39, whereinthe configuration data is used to configure the FPGA.